As is illustrated by FIG. 1, remote management systems consist of a management platform 102 in the customer device, a remote management server 104 in the network, and a remote management protocol 107 for communication between a management client or agent 103 running on the management platform 102 and the remote management server 104.
An example management platform is the OSGi (Open Service Gateway initiative) service platform, which is a Java-based service platform that runs on top of a Java Virtual Machine (JVM) inside the customer device that is remotely managed. Presence of an OSGi service platform in the customer device enables remote installation, update, invocation, removal, etc. of service objects, i.e. software components such as for instance a File Transfer Protocol (FTP) service, from an auto configuration server anywhere in the network without disrupting the operation of the customer device. This way, installation of a service object, upgrading the service object to a new version, re-configuring the service object, adding or activating new features of the service object, and removal of the service object from the customer device, is made possible without dispatching a technician to the customer premises and without requiring an intervention by the customer. Thanks to the management platform, the software services (service objects) and applications (bundles) running on a single customer device or on different customer devices within the same home network can share their capabilities with each other.
The management agent or management client 103 serves as an interface between the service object 111 and the remote management server 104. On the one hand, the management agent 103 enables the management platform 102 in the customer device to expose manageable parameters of the service object 111 to the remote management server 104, on the other hand, the management agent 103 serves as a master coordinating and controlling the lifecycle and the parameter configuration of the bundle(s) installed on a CPE.
One of the roles of the management protocol is to provide a mechanism by which the auto configuration server can securely read or write parameter values to configure the service object software in the customer device and eventually monitor the status and statistics of the customer device. An example management protocol for secure remote management of customer devices is the TR-069 protocol defined by the DSL Forum in its Technical Report TR-069, entitled “CPE WAN Management Protocol” that can for instance be retrieved from the Internet via the following URL:                http://dslforum.org/aboutdsl/tr_table.html        
The TR-069 protocol is Remote Procedure Call (RPC) based, i.e. a generic message based mechanism by which the auto configuration server is able to read/write/configure parameters and parameter attributes of a software component running on a CPE device. Each parameter consists of a name-value pair. The name identifies the particular parameter and has a hierarchical structure similar to files in a directory, the different levels being separated by a “.” (dot). The value of a parameter may be one of several defined data types. Each parameter further may be defined as a read-only or read-write parameter depending on whether the auto configuration server is allowed to only read the parameter or also to change the value of the parameter. In order to expose a service object to the auto configuration server, the names and values of the remotely manageable parameters of that service object are first communicated to the auto configuration server in response to for instance the TR-069 GetParameterValues instruction. Thereafter, the attributes of the parameters may be communicated in response to for instance the TR-069 GetParameterAttributes instruction.
Alternative remote management protocols are for instance the Open Mobile Alliance-Device Management (OMA-DM) protocol and the Simple Network Management Protocol (SNMP).
A particular example could be an HyperText Transfer Protocol (HTTP) service object that is installed on an ADSL or VDSL modem for client-server communications. All parameters of the HTTP service object constitute the service object representation of the HTTP service object, for instance represented by 112 in FIG. 1 if 111 is assumed to represent the HTTP service object. An example parameter is the number or identification of the port where the HTTP service listens to. The ADSL or VDSL modem is supposed to have an OSGi platform running on top of a Java Virtual Machine. The OSGi platform 102 enables to share the capabilities of the HTTP service object 111 with other applications, e.g. a web browser or a local web server. Via a TR-069 management agent 103 installed on top of the OSGi platform 102, the parameters of the HTTP service object 111 can be made visible and accessible to an auto configuration server (ACS) 104 in the DSL network or indirectly to any other TR-069 aware bundle. However, the bundle 101 where the HTTP service 111 forms part of thereto must explicitly announce the HTTP service object 111 to the local management agent 103, e.g. a TR-069 management agent, via a protocol specific interface or external service object representation 113, e.g. a TR-069/OSGi interface. Although drawn differently in FIG. 1, it is noticed that the external service object representation 113 can directly couple with the service object.
There are several drawbacks resulting from the known way to expose service objects and their parameters to a remote manager. Firstly, every bundle must implement the same but remote protocol specific interface and must consequently conform to the behaviour, object and data model structure imposed by the remote management protocol. This is illustrated by FIG. 2 which shows a first bundle 201 with two service objects 211a and 211b whose service object representations 212a and 212b are exported to the TR-069 management agent 203 via respective TR-069/OSGi interfaces 208a and 208b. Another bundle, Bundle x or 201x in FIG. 2, must implement the same TR-069/OSGi interface 208n to export the service object representation 212n of another service object 211n to the TR-069 management agent 203 in order to enable the latter to further expose the manageable parameters and methods of that service object 211n via the TR-069 protocol 207 to the TR-069 auto configuration server 204. The TR-069 interface for instance serves as an instrument to perform the TR-069 remote procedure calls such as GetParameterNames, GetParameterValues and SetParameterValues. The remote protocol specific interface maps the TR-069 parameters and procedures onto the internal parameters and methods of the bundle, 212a, 212b . . . 212n. In case of an audio bundle for instance, the TR-069 parameter “devices.services.OSGI.audio.volume” is mapped onto the Java parameter “Volume” in the audio bundle, and the TR-069 procedure call GetParameterValues for that parameter is mapped onto the Java method “GetVolume” available in the bundle. The implementation of such remote protocol specific interfaces is a repetitive task that must be executed for every bundle that desires to export a service object for remote management. Every bundle that implements one or more protocol specific interfaces, e.g. TR-069 interfaces, must provide functionality to query and map the TR-069 parameters or external service object representation to the internal representation of the service object, e.g. 112 in FIG. 1 or 212a, 212b and 212n in FIG. 2.
Another drawback of the prior art way of announcing and exposing service objects to a remote management server is that it ties each bundle to a specific remote management protocol. For each type of remote management protocol, e.g. TR-069, OMA-DM, SNMP, etc. a different bundle must be developed which implements the remote protocol specific interface for exposing the service object representation to the corresponding management agent. A TR-069 aware bundle cannot be used on an OMA-DM or SNMP based service platform.
The known mechanism for exposing service objects based on protocol specific interfaces is further limited in that it only provides remote access to the functionality that is exposed by the bundle and in its flexibility in case the underlying service object changes.
It is an objective of the present invention to provide a system and method for remote management of service objects in bundles that does not require implementation of protocol specific interfaces resulting in protocol specific bundles. It is a further objective of the present invention to provide a system and method for remote management of service objects which is more flexible in case of modification of the service object(s), and which does not restrict remote access to the functionality exposed by the bundle.